Ethan's Notes

Appearance

上下文工程 ​

1. 大白话：这是什么？解决什么痛点？ ​

上下文工程可以理解成 LLM 的“内存管理”。Prompt Engineering 主要关心“指令怎么写”，比如角色、任务、格式；Context Engineering 更关心“每次调用模型前，窗口里到底放什么信息、按什么顺序放、什么时候该删掉或压缩”。

在 Agent 场景里，模型看到的不只是用户一句话，还会有系统规则、历史对话、用户记忆、RAG 检索证据、工具 Schema、工具调用结果、中间计划等。上下文工程要解决的核心问题是：在有限 Token 预算里，把真正能帮助模型做对决策的信息放进去，把噪声、过期信息、重复工具结果及时清掉。

它主要解决三个痛点：

  • 上下文腐化：窗口越长不等于效果越好。把大量文档、历史、日志全塞进去，模型会被噪声干扰，关键事实反而被淹没。
  • Lost in the Middle：模型更容易注意开头和结尾，中间的关键限制条件容易被看漏，所以关键约束要放在高优先级位置。
  • 长任务失忆：Agent 跑多轮工具调用后，窗口会被旧结论、工具结果和中间废话填满，需要压缩历史、结构化笔记或外部记忆来维持任务状态。

所以面试里可以一句话概括：上下文工程不是“给模型塞更多资料”，而是“在每次调用前组装一个高信噪比的信息工作台”。

2. 底层机制与高频考点 ​

底层可以按 Context Assembler 来理解：每次调用 LLM 前，系统先加载静态规则和安全边界，再结合当前用户问题提取目标，然后召回 RAG 证据、用户记忆、历史摘要和可用工具，最后做重要性排序与 Token 预算裁剪。

一个比较完整的组装链路是：

  1. load_system_constraints：加载系统规则、权限边界、输出格式和安全策略。
  2. extract_current_goal：从用户输入和会话状态里抽取当前真正要完成的目标。
  3. retrieve_rag：按目标检索知识库、业务文档或数据库证据。
  4. recall_memory：召回用户偏好、历史事实和长期记忆。
  5. select_tools：根据目标和证据挂载本轮真正需要的工具 Schema。
  6. compact_history：压缩旧对话和旧工具结果，保留关键决策、失败原因和未完成事项。
  7. rank：把安全约束、当前目标、关键证据排到更显眼的位置。
  8. fit_token_budget：根据 Token 预算决定保留原文、摘要、引用还是丢弃。

高频对比点：

  • Prompt Engineering vs Context Engineering：Prompt 解决“模型该按什么指令做”，Context 解决“模型实际看到了什么世界”。复杂 Agent 里，只优化 Prompt 不够，因为工具结果、记忆、检索证据和安全边界都会影响模型决策。
  • 预检索 vs 按需加载：预检索适合 FAQ、固定知识库问答，链路简单但容易一次性塞入噪声；按需加载适合代码库分析、故障排查和开放式 Agent 任务，先暴露轻量索引或工具，再按需要读取细节，但延迟和工具导航要求更高。
  • 长上下文 vs 高信噪比：即使模型支持 100K、1M 上下文，也不代表能稳定利用满窗口信息。生产系统更关注关键事实是否突出、证据是否可追溯、成本和延迟是否可控。
  • Compaction、结构化笔记、Sub-agent 的区别：Compaction 负责把旧对话压成摘要；结构化笔记把任务进度、关键决策、下一步动作写到外部状态；Sub-agent 用来隔离大范围探索，最后只把高密度结论返回给主 Agent。

面试防坑点是：不要把上下文工程说成“RAG 多检索一点”。RAG 只是上下文来源之一，上下文工程还包括工具 Schema 的挂载顺序、历史压缩、记忆召回、安全边界、Token 预算、证据排序和失败降级。

3. 🎯 实战口径 ​

在我的 [[苍穹外卖AI客服]] 项目里，上下文工程落在 Spring AI Advisor 链上。用户一句“帮我把最近两个还没送到的订单退了”进来后，系统不能直接把历史聊天和所有工具都扔给模型，而是要先做意图识别和上下文组装：注入用户身份、当前订单状态、历史偏好、可用工具、RAG FAQ 证据，再把取消订单这种高风险操作的安全边界放到固定高优先级区。

我实际设计里有几个关键点：

  • 用户上下文注入：把用户 ID、订单上下文、画像记忆放进当前请求，但只放当前任务需要的字段，避免把完整用户历史塞进窗口。
  • RAG 和语义缓存分层：FAQ 类问题先走本地语义缓存，高置信命中就短路返回；不命中再走 RAG 和 LLM，减少无意义上下文注入和推理成本。
  • 工具 Schema 按阶段挂载：不是所有工具一开始全暴露，而是根据识别出的意图选择订单查询、取消订单、退款等相关工具，降低模型错选工具的概率。
  • 工具调用结果清洗：订单查询这类工具返回后，Java 端会解析出稳定字段，比如订单 ID、状态、金额，再作为结构化参数传给后续步骤，避免让模型从一大段自然语言工具结果里自己猜。
  • 长任务和死循环防护：SafeToolCallAdvisor 会检查重复工具签名和最大工具调用轮次。如果模型反复用相同参数查同一个订单，说明上下文已经不足或任务状态混乱，就短路返回兜底提示，避免 Token 空转和危险操作扩散。

如果面试官问我“为什么不直接依赖大模型长上下文”，我的回答是：长上下文只能说明放得下，不代表模型能稳定用好。我的项目里更关注高信噪比和代码侧约束，把关键上下文做结构化、排序和裁剪，把高风险操作交给 Java 端状态机、权限校验和工具结果解析来兜底。这样 Agent 才不是单纯靠 Prompt 聊天，而是有一套可控的上下文组装和执行边界。

相关链接：[[苍穹外卖AI客服]]